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CLAIMS : 

What is claimed: 

1. A data packet retransmission arrangement comprising: 

at least one client unit associated with at least one destination; 

a source of data packets, said source transmitting the data packets to said at least 
one client unit using a real-time transport protocol, said data packets representing 
real-time audio or video, said client unit operable for receiving said data packets on 
behalf of said at least one destination; and 

at least one server unit operable to receive a copy of each said data packet that said 
source transmits to said client unit; 

said client unit being further operable, responsive to a received packet being 
indicative of an error, for sending to said server, rather than to said source, a 
, request to retransmit that one of the data packets that said server received from said 
source, that will correct said error; 

wherein said at least one client unit and said at least one server unit operate 
" independently of said source and said at least one destination. 

2. The arrangement according to claim 1, wherein said client unit includes: 

a detector for determining if an incoming data packet is in a proper sequence; 

"a playback buffer for storing each said incoming data packet in a time order; and 

means for generating said request to retransmit to said server unit if said incoming 
data packet is out of sequence. 

3. The arrangement according to claim 2, wherein said detector calculates an 
inter-packet delay if said incoming data packet is out of sequence and inserts each 
said out of sequence incoming data packet in said playback buffer to form a repaired 
packet stream. 

4. The arrangement according to claim 3, wherein a repaired packet stream is sent from 
said playback buffer to said at least one destination in said time order. 
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5. The arrangement according to claim 1, wherein said client unit sends out at least 
another request to retransmit after a given interval. 

6. The arrangement according to claim 5, wherein said given interval is a multiple of 
an average round trip time between said client unit and said server unit. 

7. The arrangement according to claim 1, wherein said server unit responds to said 
request to retransmit by retransmitting a lost data packet to said client unit . 

8. The arrangement according to claim 7, wherein said request to retransmit includes a 
sequence number, a retransmission request number and a requesting client unit number. 

9. The arrangement according to claim 1, wherein said server unit includes a retransmit 
buffer for storing a given number of data packets. 

10. The arrangement according to claim 1, wherein said data packets are sent using a 
real time transport protocol, further wherein: 

said client unit is operable to determine if an incoming data packet is out of sequence 
and is further operable to generate said request to retransmit for a lost data packet 
-if said incoming data packet is out of sequence; 

said server unit being responsive to said request by sending said copy of said lost 
data packet to said client unit; and 

said client unit being further operable to send said lost data packet in a time order 
to said destination. 

11. A method for retransmitting data packets, said method comprising the steps of: 

transmitting data packets from a source to at least one client and to at least one 
server using a real-time transport protocol, said data packets representing real-time 
audio or video, said client unit associated with at least one destination and operable 
for receiving said data packets on behalf of said at least one destination; and 

responding to a received packet being indicative of an error, by having said client 
request retransmission of said data packets from said server, rather than said source, 
that will correct said error; 

wherein said at least one client and said at least one server operate independently of 
said source and said at least one destination. 

12. The method according to claim 11, wherein said step of responding includes the step 
of correcting said error in said client unit by forming a repaired packet stream. 

13. The method according to claim 11, wherein said step of responding further includes 
- the steps of : 

determining if an incoming data packet is in a proper sequence; 

" buffering a given set of said data packets in said client unit in a given time order in 
response to whether said incoming data packet is out of sequence; 

generating a retransmission request with a set of identification parameters if said 
incoming data packet is out of sequence and is a lost data packet; 

'transporting a copy of said lost data packet from said server unit to said client unit; 
and 

inserting said copy of said lost data packet in said time order to form a repaired 
packet stream. 

14. The method according to claim 11, wherein said step of responding includes the step 
of sending another retransmission request after waiting a given duration for a copy of 
a lost data packet from said server unit. 

15. The method according to claim 11, further including the step of generating at least 
one lost data packet indicator corresponding to each said error. 
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16. An apparatus for retransmitting data packets, said apparatus comprising: 
a playback register associated with at least one destination; 

a source of data packets, said source transmitting the data packets to said playback 
register using a real-time transport protocol, said data packets representing real-time 
audio or video, said playback register operable for receiving said data packets on 
behalf of said at least one destination; and 

. a retransmit register for receiving a copy of each said data packets that said source 
transmits to said playback register; 

said playback register being further operable, responsive to a received packet 
indicative of an error, for sending to said retransmit buffer, rather than to said 
source, a request to retransmit that one of the data packets that said retransmit 
register received from said source that will correct said error; 

- wherein said playback register and said retransmit register operate independently of 
said source and said at least one destination. 

.17. The apparatus according to claim 16, wherein: 

said playback register is operable to determine an out of sequence incoming packet and 
hold a given set of packets; 

said retransmit register is operable to send a copy of a lost data packet to said 
playback register; and 

said playback register is further operable to insert said copy of said lost data packet 
from said retransmit register into said set of packets in a time order to forro a 
repaired packet stream. 

18. The apparatus according to claim 16, wherein said data packets are sent over a real 
time transport protocol and said playback register uses said protocol format to place a 
set of identifying information regarding a lost packet. 

19. The apparatus of claim 16, wherein said playback register is a circular register 
and has an active region. 

20. The apparatus of claim 16, wherein said playback register maintains a time order of 
said data packets and transmits said data packets at a given inter-packet interval. 

21. A system for transmission of packet streams between at least one source and at 
least one receiver using a real-time transport protocol, said data packets representing 
real-time audio or video, said system comprising: 

at least one server unit being operable to receive a packet stream from said source; 
and 

at least one client unit being operable to detect an error in said packet stream from 

- said source and request retransmission of a lost packet from said server, rather than 
from said source; 

said client unit being further operable to send a repaired packet stream to said 
receiver, said repaired packet stream including said lost packet; 

wherein said at least one client unit and said at least one server unit operate 
independently of said source and said receiver. 

22. The system according to claim 21, wherein: 

said client unit being further operable to determine if a packet is out of sequence; 
and 

said client unit being further operable to store said packet and mark an intermediate 
set of packets as lost if said packet is out of sequence. 

23. The system according to claim 21, wherein: 
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said client unit being operable to insert a retransmitted lost packet in a time order 
to form said repaired packet stream; and 

said client unit being further operable to send said repaired packet stream in said 
time order to said receiver. 

24. The system according to claim 21, wherein: 

said server unit being further operable to store M number of packets, each said packet 
having a sequence number; and 

said server unit being further operable to retrieve said packet by locating said packet 
by said sequence number modulo M. 

25. The system according to claim 24, wherein said M is a power of 2. 
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CLAIMS : 

What is claimed is: 

1. A system for communicating digital audio signals over a randomly connected link 
between two transceivers, comprising: 

first and second sender/receiver units communicating with each other via a random 
network connection and configured for both transmitting and receiving data packets 
representative of audio information, each packet containing an index to uniquely 

identify the packet; 

means for causing the first sender/receiver unit to start a counter and an adjustment 
timer to determine a number of lost packets for a specified time period, if a 
difference between the index of a new packet and the index of a last previous packet is 
greater than one; and 

means for prompting the second sender/receiver unit to retransmit to the first 
sender/receiver unit at least some of the data packets when the number of lost packets 
for the specified time exceeds a predetermined threshold. 

' 2 . A method for recovering lost packets representing audio data in a network 

environment comprising steps, performed by a receiving station in the network, of: 

• receiving a new audio data packet from a sending station in the network, wherein the 
new packet contains a packet index, wherein the packet index is a numerical value that 
identifies the order of transmission of the new packet; 

storing a packet index of a last previous packet in a memory; 

' comparing the stored packet index and the packet index of the new packet to yield a 
difference; 

if the difference is greater than one, starting an adjustment timer and a the counter 
to determine a number of lost audio packets for a specific period of time; 

initiating a lost audio packet recovery procedure, if the adjustment timer and the 
counter show that the number of lost packets counted by the counter exceeds a 
predetermined threshold for the number of lost audio packets for the time specified by 
the adjustment timer; and 

forwarding lost audio packet recovery information to the sending station, as part of 
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the lost audio packet recovery procedures. 

3. The method as recited in claim 2, further comprising the step of: 

if the difference exceeds one half the span of possible packet index values, 
considering the newly received audio packet out -of -sequence and discarding the newly 
received packet . 

4. The method as recited in claim 2, further comprising the step of: 

if the adjustment timer reaches the specified time and the count is under a 
■ predetermined threshold for a predetermined period of time, terminating the lost audio 
packet recovery process. 

5. The method as recited in claim 2, further comprising the step of: 

if a number of lost audio packets counted by the counter during the time specified by 
the adjustment timer and is under a predetermined threshold, terminating the lost audio 
. packet recovery process. 

6. The method as recited in claim 2, further comprising steps, performed by the 
receiving station, of: 

sending a request to the sending station for encoder/decoder parameter changes; 

allocating a queue in memory to receive both a newly transmitted audio packet and a 
re-transmitted audio packet that are transmitted together/ 

receiving both the newly transmitted audio packet and the re- transmitted audio packet; 
stopping the lost audio packet process; and 

resetting a decoder to accept a plurality of new audio data packets transmitted by the 
sending station. 

7. The method as recited in claim 6, further comprising the step of: 

if the re- transmitted audio packet is a duplicate of a packet that has already been 
received, discarding the re- transmitted audio packet. 

8. The method as recited in claim 6, further comprising the step of: 

if the re- transmitted audio packet is too old and not useable with the current set of 
received audio packets, discarding the re- transmitted audio packet. 

9. The method as recited in claim 6, further comprising the step of: 

if the re-transmitted audio packet is one that was lost, reinserting the re- transmitted 
• audio packet in an appropriate position among the other audio packets to produce an 
acceptable audio signal. 

. 10. An apparatus for recovering lost packets representing audio data in a network 
environment , comprising : 

a sender/receiver unit including: 

a receiver; and 

means for sending data, the sender/receiver unit communicating with a remote 
sender/receiver unit in the network, the receiver causing the sender/receiver unit to 
receive a new packet from the remote sender/receiver unit, wherein the packet contains 
a packet index, wherein the packet index is the numerical value that identifies the 
order of transmission for the packet; the receiver being further configured to perform 
steps, including: 

storing a packet index of a last packet previously received in memory, 

comparing the stored packet index and the packet index of the new packet to yield a 
difference; 
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starting, if the difference is greater than one, an adjustment timer and a counter to 
determine the number of lost audio packets for a specific period of time; 

initiating a lost audio packet recovery procedure, if the adjustment timer and the 
counter show that the number of lost packets counted by the counter exceeds a 
predetermined threshold for the number of lost audio packets for the time specified by 
the adjustment timer; and 

causing the sender /receiver unit to forward lost audio packet recovery information to 
the remote sender/receiver unit as part of the lost audio packet recovery procedure. 

11. The apparatus as recited in claim 10, wherein the receiver considers the newly 
received audio packet out -of -sequence and discards the newly received packet, if the 
difference exceeds one half the value of the span of possible packet index values. 

12. The apparatus as recited in claim 10, wherein the receiver terminates the lost 
audio packet recovery process if the adjustment timer reaches the specified time and 
the count is under a predetermined threshold for a predetermined period of time. 

13. The apparatus as recited in claim 10, wherein the receiver terminates the lost 
audio packet recovery process, if the number of lost audio packets counted by the 

'counter during the time specified by the adjustment timer is under a predetermined 
threshold. 

14. The apparatus as recited in claim 10, in which the receiver is further configured 
to perform steps, including: 

causing the sender/receiver unit to send a request to the remote sender/receiver unit 
for encoder/decoder parameters changes; 

allocating a queue in memory to receive both a newly transmitted audio packet and a 
retransmitted audio packet that are transmitted together; 

causing the sender/receiver unit to receive both the newly transmitted audio packet and 
the re- transmitted audio packet; 

stopping the lost audio packet recovery process; and 

resetting a decoder to accept a plurality of new audio data packets transmitted by the 
remote sender/receiver unit . 

15. The apparatus as recited in claim 14, wherein the receiver discards the 

re- transmitted audio packet, if the re- transmitted audio packet is a duplicate of a 
packet that has already been received. 

16. The apparatus as recited in claim 14, wherein the receiver discards the 

re- transmitted audio packet, if the re- transmitted audio packet is too old and not 
* useable with the current set of received audio packets. 

17. The apparatus as recited in claim 14, wherein receiver inserts the re -transmit ted 
audio packet in an appropriate position among the other audio packets to produce an 
acceptable audio signal, if the re -transmit ted audio packet is one that was previously 
lost . 

18 . A system for recovering lost packets representing audio data in a network 
environment, comprising: 

first and second sender/receiver units communicating with each other and being 
configured for both transmitting and receiving packets representing audio data, each 
packet containing a index to uniquely identify the packet; 

means for causing the first sender/receiver unit to start a counter and an adjustment 
timer to determine a number of lost packets for a specified time period, if a 
difference between the index of a new packet and the index of a last previous packet is 
greater than one; and 

means for causing the first sender/receiver unit to initiate a lost packet recovery 
procedure when the number of lost packets for the specified period exceeds a 
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predetermined threshold, the lost packet recovery procedure includes sending a lost 
packet recovery information; 

means for causing the second sender/receiver unit to receive the lost packet recovery 
information; 

means for causing the second sender/receiver unit to provide a compression method 
suitably selected for recovery of the lost packets; 

means for causing the first sender/receiver unit to prepare for recovering any lost 
packets, a lost packet being resent in tandem with a newly sent packet; and 

means for causing both of the first and second sender/receiver units to stop the lost 
packet recovery procedure when the number of lost packets is under a specified 
threshold . 

19. A method for recovering lost packets representing audio data in a network 
environment comprising: 

receiving, by a receiver, packets representing audio data, each packet containing a 
index to uniquely identify the packet; 

counting, in the receiver, a number of lost packets for a specified time period if a 
difference between the index of a previously received packet and the index of a 
currently received packet is greater than one; 

initiating, by the receiver, a lost packet recovery procedure when the number of lost 
packets for the specified period exceeds a predetermined threshold, the lost packet 
recovery procedure includes sending, from the receiver to a sender, a lost packet 
recovery information; 

providing, in the sender, a compression method suitably selected for recovery of the 
lost packets; 

preparing, in the receiver, to recover any lost packets resent by the sender, for each 
lost packet resent by the sender the lost packet is sent in tandem with a new packet; 
and 

sending from the receiver to the sender a stop recovery message when the number of lost 
packets is under a specified threshold. 
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PRIMARY -EXAMINER: Hsu; Alpus H. 
ASSISTANT-EXAMINER: Qureshi; Afsar M. 
ATTY- AGENT- FIRM: Glenn; Michael A. 



ABSTRACT: 

A resegmentation entity implements a TCP resegmentation technique wherein a receiving 
host receives packets that appear as if it they have been transmitted specifically for 
the receiving host's MTU. The receiving host does not require the buffering and CPU 
utilization necessary for IP reassembly. Thus, the receiving host has a lower latency 
when receiving IP datagrams that contain resegmented TCP segments than it would if it 
needed to re- assemble an IP datagram from fragments before it could process the TCP 
segment. Further, the sending host transmits TCP segments at its largest MTU, without 
regard to the receiving station's MTU, knowing that the intermediate routing entity 
insures that TCP resegmentation occurs. In the event that an IP datagram containing a 
resegmented TCP segment is lost, the sending host only has to retransmit the actual TCP 
' data that was lost, and not the complete TCP segment. 

24 Claims, 6 Drawing figures 
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ABSTRACT : 

In a network with a sending system networked to at least one receiving system, it is 
sometimes desirable to transfer relatively short messages between the sending system 
•and one or more receiving systems in a highly reliable yet highly efficient manner. The 
present invention defines two short message protocols, one of which relies on a 
statistical model and the other of which uses positive acknowledgement to track receipt 
of transmitted packets by intended recipient. The statistical reliability mode is based 
on the observation that for each packet in a message that is transmitted, the 
probability that at least one packet of the message is received by a given system 
increases. Thus, in the statistical reliability mode messages are divided into a 
guaranteed minimum number of packets, with additional packets being added if the 
message length is insufficient to fill the minimum number of packets. The positive 
reliability mode of the present invention periodically sets an acknowledgement flag in 
the packets transmitted for a message. Receiving systems send an acknowledgement in 
response to receipt of that packet. The sending system tracks receipt of 
acknowledgements by intended recipient and retransmits any unacknowledged packets so as 
to positively assure the packets are received. Receiving systems send negative 
acknowledgements to request retransmission of missing packets. Negative acknowledgement 
suppression is implemented at both the sender and receiver to prevent a flood of 
negative acknowledgements from overwhelming the network. Packets are transmitted by the 
sending system at a transmission rate selected to avoid any adverse impact on the 
packet loss rate of the network. 

29 Claims, 14 Drawing figures 
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